[EventPipe] Add dotnet_ipc_created mapping#123779
Merged
mdh1418 merged 5 commits intodotnet:mainfrom Feb 5, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a dotnet_ipc_created memory mapping to signal when a .NET process's diagnostic port is ready to receive IPC commands. This provides external tracing tools with a low-overhead mechanism to detect when the runtime is ready, instead of having to poll temporary file directories. The implementation uses Linux's memfd_create syscall to create a named memory mapping that can be detected by tools like one-collect.
Changes:
- Added CMake configuration checks for
sys/mman.hheader andmemfd_createsyscall availability - Created a memory mapping named "dotnet_ipc_created" when the default diagnostic listen port is successfully initialized
- The mapping serves as a signal mechanism for external tools to detect IPC readiness
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/native/eventpipe/configure.cmake | Added CMake checks for sys/syscall.h, sys/mman.h, and __NR_memfd_create symbol |
| src/native/eventpipe/ep-shared-config.h.in | Added CMake define declarations for HAVE_SYS_MMAN_H and HAVE_MEMFD_CREATE |
| src/native/eventpipe/ds-ipc.c | Implemented the dotnet_ipc_created mapping creation using memfd_create and mmap when the default listen port is successfully created |
This was referenced Jan 30, 2026
Open
lateralusX
reviewed
Jan 30, 2026
jkotas
approved these changes
Feb 4, 2026
lateralusX
approved these changes
Feb 5, 2026
Member
Author
|
/backport to release/10.0 |
Contributor
|
Started backporting to |
4 tasks
7 tasks
steveisok
pushed a commit
that referenced
this pull request
Feb 8, 2026
Backport of #123779 to release/10.0 /cc @mdh1418 ## Customer Impact - [ ] Customer reported - [x] Found internally User_events support was added in .NET 10. The officially supported way to enable user_events is through One-Collect's [record-trace](https://github.com/microsoft/one-collect) (which dotnet-trace wraps around). Record-trace relied on an implementation detail of W^X that NativeAOT doesn't support since it doesn't support PerfMaps (see microsoft/one-collect#226), so it was belatedly discovered that user_events doesn't work for NativeAOT. Through discussions in microsoft/one-collect#226, this `dotnet_ipc_created` mapping with no permissions (PROT_NONE) was found as an acceptable minimal OS interaction to signal when the .NET process' diagnostic ports are available. ## Regression - [ ] Yes - [x] No ## Testing I tested the [User_events runtime tests](https://github.com/dotnet/runtime/tree/main/src/tests/tracing/userevents) against a locally built record-trace based on microsoft/one-collect#229 in both CoreCLR and NativeAOT on my WSL2 instance. ## Risk Low. The mapping being introduced has minimal permissions as it is a private mapping created with `PROT_NONE`. --------- Co-authored-by: mdh1418 <mitchhwang1418@gmail.com>
lewing
pushed a commit
to lewing/runtime
that referenced
this pull request
Feb 9, 2026
External tools interested in connecting to the runtime's diagnostic ports benefit from a low-overhead IO signal that a .NET process is ready to receive IPC commands, instead of trying to IO over all known temp file directories looking for diagnostic ports for each process. Following the discussion in microsoft/one-collect#226, this PR adds a new mapping, `dotnet_ipc_created`, that is created once a .NET process' singular listen port is successfully created. ## Testing userevents runtime tests now work on NativeAOT with the record-trace change microsoft/one-collect#229 ``` mihw@CPC-mihw-6KMZDM:~/repo/runtime$ ./artifacts/tests/coreclr/linux.x64.Release/tracing/userevents/basic/basic/basic.sh BEGIN EXECUTION /home/mihw/repo/runtime/src/tests/Common/scripts/nativeaottest.sh /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Release/tracing/userevents/basic/basic/ basic.dll '' traceeAssemblyPath: Starting record-trace: sudo -n /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Release/tracing/userevents/common/userevents_common/record-trace --script-file /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Release/tracing/userevents/basic/basic/native/../basic.script --out /tmp/tmpBoli5K.nettrace --log-mode console --log-filter error,one_collect::helpers::dotnet::os::linux=debug record-trace started with PID: 1543079 [record-trace] 2026-01-29T22:55:19.967428Z DEBUG one_collect::helpers::dotnet::os::linux: Registered .NET tracepoint: name=OC_DotNet_Microsoft_Windows_DotNETRuntime_1543081_All, callstacks=false, use_names=true Starting tracee process: /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Release/tracing/userevents/basic/basic/native/basic tracee Tracee process started with PID: 1543083 Waiting for tracee process to exit... [record-trace] 2026-01-29T22:55:20.093460Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543063, nspid=1543063 [record-trace] 2026-01-29T22:55:20.093476Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543063, nspid=1543063 [record-trace] 2026-01-29T22:55:20.094446Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543063, nspid=1543063 [record-trace] Recording started. Press CTRL+C to stop. [record-trace] 2026-01-29T22:55:20.097795Z INFO one_collect::helpers::dotnet::os::linux: Enabled .NET events for process: pid=1543063 [record-trace] 2026-01-29T22:55:20.098955Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543083, nspid=1543083 [record-trace] 2026-01-29T22:55:20.099085Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543083, nspid=1543083 [record-trace] 2026-01-29T22:55:20.100017Z DEBUG one_collect::helpers::dotnet::os::linux: Opened diagnostic socket: pid=1543083, nspid=1543083 [record-trace] 2026-01-29T22:55:20.104842Z INFO one_collect::helpers::dotnet::os::linux: Enabled .NET events for process: pid=1543083 Stopping record-trace with SIGINT. Waiting for record-trace to exit... [record-trace] Recording stopped. [record-trace] Resolving symbols. [record-trace] Finished recording trace. [record-trace] Trace written to /tmp/tmpBoli5K.nettrace Expected: 100 Actual: 100 END EXECUTION - PASSED ```
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
External tools interested in connecting to the runtime's diagnostic ports benefit from a low-overhead IO signal that a .NET process is ready to receive IPC commands, instead of trying to IO over all known temp file directories looking for diagnostic ports for each process.
Following the discussion in microsoft/one-collect#226, this PR adds a new mapping,
dotnet_ipc_created, that is created once a .NET process' singular listen port is successfully created.Testing
userevents runtime tests now work on NativeAOT with the record-trace change microsoft/one-collect#229